5.3 Correct Front Buffer Rendering for X

Support for double buffering introduces a new complication to mixing non-OpenGL X rendering with OpenGL rendering for SGI. When X rendering is done to an X window, the render operations should affect the front buffer of the window. So X rendering must be directed into the correct relative buffer, i.e., the front buffer.

As discussed earlier, rendering nodes virtualize the relative access to front and back buffers when using double buffering. But the X server renders all non-OpenGL rendering to all windows through a single rendering node. The X server does not rely on its rendering node for correct window clipping or to determine correctly the front or back buffer. In part this is because the X server does not bind to particular windows the way OpenGL does.

Because the X server has full knowledge of the window tree, it does its clipping in software (and sometimes with hardware assist). The use of virtualized clipping within the X server is difficult for two reasons:

• The X server renders to many more windows than OpenGL programs do. Using virtualized clipping would quickly exhaust the hardware clipping resources.
• Because the same thread in the X server does core rendering as does the validation of virtual clip resources, use of virtualized clipping would deadlock the X server.

But as discussed before, buffer swaps can be scheduled by direct renderers without the attention or knowledge of the X server. If the X server has validated the swappable DID resource of a window, it can no longer ensure rendering goes into the front buffer. The X server could query the hardware to determine state of the buffer. Querying the current front buffer would require a query per-rendering operation. Worse yet, the query's information is only valid for the instant of the query.

If the X server wants to render into the window of a double buffered window that has its swappable DID resource validated, the X server invalidates the unshared DID resource for the window. A graphics driver ioctl is used to perform the invalidation. This invalidation accomplishes two things:

• Revokes the permission of direct renderers to swap the buffer. Further attempts to swap the window will be held off and result in a message to the X server to revalidate the unshared DID resource. The swap will be delayed until the X server revalidates the resource.

• And, returns the current state of the buffer.

The overhead of the scheme is minimized because the X server only checks if it needs to revoke a double buffered window's shared DID resource during the validation of a graphics context (GC) and window. Serial numbers determine when the window and a given GC are validated with respect to each other. When the shared DID resource is validated, the serial number of the window is updated with a unique value, forcing any previously valid GCs to become invalid. Any X rendering will then force a GC validation, at which time the shared DID resource can be revoked.